LCORE- Only apply latest tag to container if it is the latest stable tag#1921
Conversation
Add a program to determine the latest stable tag and compare it to the tag that triggered the workflow run. Only apply the latest tag if they match. Update the workflow to apply the latest tag based on the results of that program. This prevents new tags for older releases from getting the latst tag applied.
|
Warning Review limit reached
More reviews will be available in 40 minutes and 29 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more credits in the billing tab to continue. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis PR adds intelligent "latest" tagging to the container image release workflow. A new Python script determines if the current Git tag is the latest stable release by filtering pre-releases and comparing versions, then the workflow conditionally applies the ChangesImage Latest Tag Detection
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/build_and_push_release.yaml (1)
56-60:⚠️ Potential issue | 🟠 Major | ⚡ Quick winGate manifest inspection on
apply_latestto prevent expected releases from failing.Line 59 always inspects
:latest, but Line 46 intentionally omitslatestfor non-latest/pre-release tags. That makes this step fail on valid runs whereapply_latest=false.Suggested fix
- name: Check manifest + if: steps.check_latest.outputs.apply_latest == 'true' run: | set -x buildah manifest inspect ${{ steps.build_image.outputs.image }}:${{ env.LATEST_TAG }}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/build_and_push_release.yaml around lines 56 - 60, The manifest inspection step ("Check manifest") always runs against :${{ env.LATEST_TAG }} causing failures when apply_latest is false; add a conditional to that step (e.g., if: ${{ env.apply_latest == 'true' }} or if: ${{ env.APPLY_LATEST == 'true' }} depending on your env var name) so the buildah manifest inspect ${ { steps.build_image.outputs.image }}:${{ env.LATEST_TAG }} command only executes when apply_latest is enabled; update the step metadata (the step named "Check manifest") to include this if condition and leave the existing run block unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/latest-tag.py`:
- Around line 7-12: The version_split function currently fails on tags with
non-numeric prefixes (e.g., "v1.2.3") and collapses them to (-1,), breaking
sorting; update version_split to normalize the tag string first by stripping a
leading "v" or other common prefixes and by removing or splitting off any
prerelease/build metadata (e.g., "-rc1", "+meta") so you only parse the numeric
dot-separated segments, then convert those numeric segments to ints and return
the tuple; ensure version_split still returns a sensible fallback (e.g., (-1,))
only when no numeric segments exist, so sorting of stable tags (used elsewhere)
works correctly.
---
Outside diff comments:
In @.github/workflows/build_and_push_release.yaml:
- Around line 56-60: The manifest inspection step ("Check manifest") always runs
against :${{ env.LATEST_TAG }} causing failures when apply_latest is false; add
a conditional to that step (e.g., if: ${{ env.apply_latest == 'true' }} or if:
${{ env.APPLY_LATEST == 'true' }} depending on your env var name) so the buildah
manifest inspect ${ { steps.build_image.outputs.image }}:${{ env.LATEST_TAG }}
command only executes when apply_latest is enabled; update the step metadata
(the step named "Check manifest") to include this if condition and leave the
existing run block unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 28c418c1-a2fc-42f2-a92d-4078875401c7
📒 Files selected for processing (2)
.github/workflows/build_and_push_release.yamlscripts/latest-tag.py
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)
- GitHub Check: black
- GitHub Check: list_outdated_dependencies
- GitHub Check: bandit
- GitHub Check: spectral
- GitHub Check: integration_tests (3.12)
- GitHub Check: radon
- GitHub Check: Pylinter
- GitHub Check: unit_tests (3.13)
- GitHub Check: integration_tests (3.13)
- GitHub Check: unit_tests (3.12)
- GitHub Check: Pyright
- GitHub Check: mypy
- GitHub Check: build-pr
- GitHub Check: E2E: library mode / ci / group 1
- GitHub Check: E2E: library mode / ci / group 3
- GitHub Check: E2E: server mode / ci / group 3
- GitHub Check: E2E: server mode / ci / group 1
- GitHub Check: E2E Tests for Lightspeed Evaluation job
- GitHub Check: E2E: server mode / ci / group 2
- GitHub Check: E2E: library mode / ci / group 2
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-05-06T08:35:54.687Z
Learnt from: radofuchs
Repo: lightspeed-core/lightspeed-stack PR: 1690
File: .github/workflows/e2e_tests_providers.yaml:279-285
Timestamp: 2026-05-06T08:35:54.687Z
Learning: In .github/workflows/e2e_tests_providers.yaml and related e2e workflow files, the show_logs step should not use docker compose logs with --tail or --since (i.e., keep logs unbounded). The quick connectivity test runs once immediately after container startup, so the log output is small and a log tail limit is unnecessary. If you adjust this, add a rationale comment in the workflow explaining why unbounded logs are acceptable and ensure CI behavior remains deterministic.
Applied to files:
.github/workflows/build_and_push_release.yaml
🪛 ast-grep (0.43.0)
scripts/latest-tag.py
[error] 23-23: Avoid command injection
Context: subprocess.check_output(["git", "tag"], text=True)
Note: Security best practice.
(command-injection-python)
[error] 23-23: Command coming from incoming request
Context: subprocess.check_output(["git", "tag"], text=True)
Note: [CWE-20].
(subprocess-from-request)
[error] 23-23: Use of unsanitized data to create processes
Context: subprocess.check_output(["git", "tag"], text=True)
Note: [CWE-78].
(os-system-unsanitized-data)
🪛 zizmor (1.25.2)
.github/workflows/build_and_push_release.yaml
[error] 41-41: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
samdoran
changed the title
The image may not get the latst tag applied, so this step could inspect the incorrect image. Use the output from the build_image step to ensure the correct image is always inspected.
tisnik
left a comment
tisnik
left a comment
There was a problem hiding this comment.
Nice one, it will even works for version 10 :)
2 participants
Description
Add a program,
latest-tag.py, to determine the latest stable tag and compare it to the tag that triggered the workflow run. Only apply the latest tag if they match.Update the workflow to apply the latest tag based on the results of that program.
This prevents new tags for older releases as well as prereleases from getting the latest tag applied.
Alternative approach
A simpler approach would be to change the trigger for the build-and-push-release job to something like
'0.5*. That requires keeping the trigger and the release tags in sync. While this change is a bit more complicated, it should require no changes when the tagsType of change
Tools used to create PR
Identify any AI code assistants used in this PR (for transparency and review context)
Related Tickets & Documents
None
Checklist before requesting a review
Testing
These tests were run with the current tags as of today which are:
Local Testing (without
GITHUB_OUTPUTdefined)Local Testing (with GITHUB_OUTPUT)
I also did some testing with tags such as
1.0.0and0.5.10to make sure the sorting worked as expected.Summary by CodeRabbit
latestimage tag only to stable releases, not pre-releases. Pre-release versions will now use their specific version tag only.